Method and system for adaptive security in cloud-based services

ABSTRACT

Certain embodiments may generally relate to controlling access to data held in the cloud. A method for controlling access to data held in the cloud may include determining, at a cloud server, the validity of user credentials received from a user device. The method may also include receiving context data related to the user device based on the validity of the user credentials. The method may further include synchronizing the context data with the cloud server. In addition, the method may include enforcing context-sensitive security checks on requests made by the user for resources based on the sensor data collected by the user device.

CROSS REFERENCE TO RELATED APPLICATION

This is a continuation application of U.S. patent application Ser. No.15/785,858, filed Oct. 17, 2017, which application claims priority toU.S. Provisional Application No. 62/411,445 filed on Oct. 21, 2016. Theentire contents of the above-referenced applications are herebyincorporated by reference in their entirety.

FIELD OF THE INVENTION

Certain embodiments may generally relate to controlling access to dataheld in the cloud. More specifically, certain embodiments of the presentinvention generally relate to controlling access to data held in thecloud using context information pertaining to a user's accessing mobiledevice.

BACKGROUND OF THE INVENTION

File storage is one of the most popular use cases for cloud computing. Acloud-based file sharing service may generally adopt an open-sourcedevelopment model, providing a universal way to access shared filesthrough any Web browser from desktop or mobile devices.

The access control mechanism implemented in a current cloud-based servermay use database queries to determine whether an end-user is allowed tocreate, read, update, delete, or share a document to other users. It mayalso assume that the access control decisions are based on propertiessimilar to those of a desktop file system. However, in a mobile worldwhere people in different environments have access to differentdocuments, such access control decisions need to take into accountricher and changing contextual situations that cannot be predeterminedonly by the content and user permissions of intended files.

Existing context-aware access control proposals demonstrate the need tosupport rich context-aware access control requirements for mobileend-users, but they have not yet been applied to cloud-based services.In order to develop a systematic method for integrating a context-awareaccess control system to a cloud-based application, it is desired toreengineer current cloud servers to replace discretionary access controlmechanisms with a more expressive attribute-based access control system.

Further, the Extensible Access Control Markup Language (XACML) is astandard for defining the language for decoratively specifying dynamicaccess control policies as well as the process to enforce such policies.According to the standard, a policy-based process for access control mayprovide both Policy Decision Points (PDP) and Policy AdministrationPoints (PAP). The PAP supports the interfaces needed to set up the rootpolicy as a predefined set of rules, while the PDP evaluates thepolicies that apply to a given access request in order to make theaccess control decisions.

Additionally, there are many cloud-based services that are accessed bytheir users using diverse mobile devices. Security mechanisms in thoseservices are usually related to authentication and authorization.Increasingly contextual information from the user devices provides arich source of information for enhancing security of those services.Enabling context-awareness in security mechanisms of existingcloud-services is a difficult engineering challenge because it is notclear how applications should sense the user context, and how the senseddata should be used.

There is a need, therefore for both policy decision and administrationpoints to be context-aware in order to allow different decisions bypolicy rules to reflect the context-of-use of the system for whichaccess control is required. Due to the wide adoption of mobile devices,such contextual situations are no longer based on the consent of files.Instead, they need to take into account the values of a range ofvariables sensed by the devices.

Additional features, advantages, and embodiments of the invention areset forth or apparent from consideration of the following detaileddescription, drawings and claims. Moreover, it is to be understood thatboth the foregoing summary of the invention and the following detaileddescription are exemplary and intended to provide further explanationwithout limiting the scope of the invention as claimed.

SUMMARY OF THE INVENTION

Embodiments of the present invention overcome the above-mentioned andother drawbacks by providing methods and system for using contextualparameters to make access-control policy decisions that reflect thecontext-of-use of the system for which access control is required.

According to a first embodiment, a method for controlling access to dataheld in the cloud may include determining, at a cloud server, thevalidity of user credentials received from a user device. The method mayalso include receiving context data related to the user device based onthe validity of the user credentials. The method may further includesynchronizing the context data with the cloud server. In addition, themethod may include enforcing context-sensitive security checks onrequests made by a user for resources based on the sensor data collectedby the user device.

In the method of the first embodiment, the context data may include dataabout a state of a physical world outside of the user device, and thecontext data may include data about a state of the user device itself.Further, the context data about the state of the physical world outsideof the user device may include a user identity, a global positioningsystem location of the user device, and an accelerometer reading. Inaddition, the context data about the state of the user device itself mayinclude applications running on the user device at a given time, abattery level of the user device, and screen brightness of the userdevice.

In the method of the first embodiment, access to the resources may besubject to one or more preconditions related to the context data. Themethod may also include determining if the requests for resources arecompliant with access control policies of the cloud server in additionto enforcing the context-sensitive security checks. Further, thecontext-sensitive security checks may vary based on a sensitivity levelof the resources.

According to a second embodiment, a cloud server for controlling accessto data held in the cloud may include at least one processor, and atleast one memory including computer program code. The at least onememory and the computer program code may be configured to, with the atleast one processor, cause the apparatus at least to determine, at acloud server, the validity of user credentials received from a userdevice, receive context data related to the user device based on thevalidity of the user credentials, synchronize the context data with thecloud server, enforce context-sensitive security checks on requests madeby a user for resources based on the sensor data collected by the userdevice.

In the apparatus of the second embodiment, the context data may includedata about a state of a physical world outside of the user device, andthe context data comprises data about a state of the user device itself.Further, the context data about the state of the physical world outsideof the user device may include a user identity, a global positioningsystem location of the user device, and an accelerometer reading. Inaddition, the context data about the state of the user device itself mayinclude applications running on the user device at a given time, abattery level of the user device, and screen brightness of the userdevice.

In the apparatus of the second embodiment, access to the resources maybe subject to one or more preconditions related to the context data.Further, the at least one memory and the computer program code mayfurther be configured to, with the at least one processor, cause theapparatus at least to determine if the requests for resources arecompliant with access control policies of the cloud server in additionto enforcing the context-sensitive security checks. In addition, thecontext-sensitive security checks may vary based on a sensitivity levelof the resources.

According to a third embodiment, there may be provided a computerprogram, embodied on a non-transitory computer readable medium that whenexecuted by a processor, causes the processor to determine, at a cloudserver, the validity of user credentials received from a user device,receive context data related to the user device based on the validity ofthe user credentials, synchronize the context data with the cloudserver, and enforce context-sensitive security checks on requests madeby a user for resources based on the sensor data collected by the userdevice. According to the computer program of the third embodiment, thecontext data may include data about a state of a physical world outsideof the user device, and the context data may include data about a stateof the user device itself. Further, the context data about the state ofthe physical world outside of the user device may include a useridentity, a global positioning system location of the user device, andan accelerometer reading. In addition, the context data about the stateof the user device itself may include applications running on the userdevice at a given time, a battery level of the user device, and screenbrightness of the user device.

In the computer program of the third embodiment, access to the resourcesmay be subject to one or more preconditions related to the context data.Further, the computer program, when executed by the processor, mayfurther cause the processor to determine if the requests for resourcesare compliant with access control policies of the cloud server inaddition to enforcing the context-sensitive security checks. Inaddition, the context-sensitive security checks varies based on asensitivity level of the resources.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention and are incorporated in and constitute apart of this specification, illustrate preferred embodiments of theinvention and together with the detailed description serve to explainthe principles of the invention. In the drawings:

FIG. 1 illustrates a system design of hardware and software componentsaccording to certain embodiments.

FIG. 2 illustrates a flow diagram according to certain embodiments.

FIG. 3 illustrates an implementation of an AIS architecture according tocertain embodiments.

FIG. 4 illustrates an overview of an architectural design according tocertain embodiments.

FIG. 5 illustrates an exemplary policy according to certain embodiments.

FIG. 6 illustrates another exemplary policy according to certainembodiments.

FIG. 7 illustrates a further exemplary policy according to certainembodiments.

FIG. 8 illustrates yet another exemplary policy according to certainembodiments.

FIG. 9 illustrates a method according to certain embodiments.

FIG. 10 illustrates another method according to certain embodiments.

FIG. 11 illustrates a cloud-based server in use according to certainembodiments.

FIG. 12 illustrates another cloud-based server in use according tocertain embodiments.

FIG. 13 illustrates a further cloud-based server in use according tocertain embodiments.

FIG. 14 illustrates a system according to certain embodiments.

FIG. 15 illustrates another method according to certain embodiments.

In the following detailed description of the illustrative embodiments,reference is made to the accompanying drawings that form a part hereof.These embodiments are described in sufficient detail to enable thoseskilled in the art to practice the invention, and it is understood thatother embodiments may be utilized and that logical or structural changesmay be made to the invention without departing from the spirit or scopeof this disclosure. To avoid detail not necessary to enable thoseskilled in the art to practice the embodiments described herein, thedescription may omit certain information known to those skilled in theart. The following detailed description is, therefore, not to be takenin a limiting sense.

DETAILED DESCRIPTION OF THE INVENTION

The features, structures, or characteristics of the invention describedthroughout this specification may be combined in any suitable manner inone or more embodiments. For example, the usage of the phrases “certainembodiments,” “some embodiments,” or other similar language, throughoutthis specification refers to the fact that a particular feature,structure, or characteristic described in connection with the embodimentmay be included in at least one embodiment of the present invention.

Certain embodiments described herein may make use of the following threeopen-source software tools. These tools may be available under theApache Software License 2.0. One tool may include Android Mobile ContextInstrumentation Framework (AWARE). Another tool may include eXtensibleAccess Control Markup Language Light (XACMLight) Engine as a web servicesupporting the creation and management of XACML access control policies.A third tool may include Apache Axis2 server as a software tool forcreating and hosting web services.

The Adaptive Information Security (AIS) Architecture is acomputer-implemented method and system of hardware and softwarecomponents for achieving adaptive security in cloud-based web-services.The AIS architecture may include a computer-implemented method that (i)monitors the user context by non-intrusively collecting sensor data onthe client device, (ii) securely synchronizes the collected sensor datato the sever which may be on a machine separate from the cloud server,and (iii) enforces context-sensitive security checks on the user'srequests for resources based on the collected sensor data. Thesecomputer-implemented security checks may be additions to the enforcementof rule-based access control policies of the server. According tocertain embodiments, the method may be used to create a system ofadaptive security in a cloud-based document sharing system.

Referring to FIG. 1, there is shown a system design of hardware andsoftware components, according to certain embodiments, where adaptivesecurity may be achieved by dividing the responsibilities between thecomponents on the client and the server sides. User Device and CloudServer are the two hardware components. Services, provided by the CloudServer, may be accessed by users using User Devices, such as smartphones and tablets, or any other similar type devices. Services mayrepresent a stack of services such as Application-as-a-Service (AaaS)and Infrastructure-as-a-Service (IaaS). The Applications box inside UserDevice may represent the client software used to access cloud services,while the Services box inside Cloud Server may represent the stack ofcloud services such as AaaS and IaaS. These two boxes by themselves mayconstitute typical cloud applications with no adaptive informationsecurity capabilities.

According to certain embodiments, the AIS architecture may integrate twosets of additional components, including, for example, AIS Monitors andAIS Controls, in order to make cloud applications adaptive to changingsecurity context. In this architecture, adaptation may be driven by theuser and organizational requirements for information security, and theuser context.

In certain embodiments, the user may interact with applications, and thetwo components in AIS Monitors to collect data about the state of thephysical world outside of the device via the device sensors (Out′Monitors), and data about the state of the device itself (In′ Monitors).The former may include the user identity, the global positioning system(GPS) location of the device, and accelerometer readings, while thelatter may include the applications running at a given time, batterylevel of the device, and/or screen brightness. The frequency at whichthe information is collected may also depend on the device capacitiesand the organizational information security goals.

In other embodiments, the data collected by AIS Monitors may be sent tothe server, which may be on a different hardware component. Further, theService Adaptation Engine may use the data collected by AIS Monitors inorder to determine the user context. This may be performed viastatistical machine learning techniques such as, for example, naiveBayes and logistic regression approaches to classification. In addition,whenever the server receives a request for resource such as a file, theService Adaptation Engine may enforce additional security constraints onthe basis of the inferred user context.

Referring to FIG. 2, there is shown a flow diagram according to certainembodiments, which shows a computer implemented method for achievingadaptive security in cloud services using the AIS architecture. Steps1-6 in FIG. 2 may represent a traditional method for authenticatingusers and enforcing rule-based access control policies on requests onfile access. In particular, at step 1, the user may enter usercredentials. At step 2, the user device may send the user credentials tothe server, and in step 3, the server may check and/or verify the usercredentials. A determination is then made by the server as to whether ornot the credentials received are valid. If it is determined that thecredentials are not valid, then the method returns to step 1. If it isdetermined that the credentials are valid, then at step 4, the user mayrequest file access.

At step 5, the user device may send the file and user identification(IDs) to the server, and at step 6, the server may apply the accesscontrol policy. Then, at step 7, the server may determine if access tothe requested file is allowed. If it is determined that access is notallowed, then the method returns to step 4. If it is determined thataccess is allowed, then at step 7, a certain context criteria may beapplied. In particular, the AIS architecture may, at step 01,continuously monitor the user context and send the context. The AISArchitecture may also, at step 02, store the context information on theserver, and then send the context.

Referring to FIG. 3, there is shown a flow diagram of an implementationof the AIS architecture according to certain embodiments. In particular,FIG. 3 shows an implementation of the AIS architecture with a realisticscenario example from a medical information systems domain. For example,as shown in FIG. 3, it may be assumed that a doctor wishes to access apatient record file using a mobile device. As shown in steps 1-3 and 0of FIG. 3 for example, the doctor may normally have to provide usercredentials together with the details of the file that the doctor wishesto access. If the authentication succeeds and if the request satisfiesthe organizational policy on access control, the doctor may be given theprivilege and access to the resource as requested. As further shown step4 of FIG. 3, with the AIS architecture, the adaptation engine mayperform additional security checks by considering the user context. If,for example, the doctor is not using the office computer provided by thehospital, the access request will be denied even through the doctor hasprovided valid credentials and even though the access control policyallows the requested access.

A more detailed description of the implementation of the AISarchitecture with respect to the medical information systems domain asan example is further provided below. Certain embodiments, however, maynot be so limited to the medical information systems domain and may beapplicable to other domains and/or cloud systems.

Context-Aware Policy Decision Point (PDP) Requirements

In one implementation according to certain embodiments, for example, andcontinuing with the above example, a hospital may be using a cloudsystem as a cloud-based Web service for keeping electronic healthrecords of the patients. The doctor may have access to records ofpatients registered under his clinic. Using a laptop registered with thehospital, the doctor may try to make changes to a patient's recordstored in the cloud system. After checking the patient's symptoms, thedoctor may wish to prescribe medicine using his personal tablet orwireless device through the Web interface of the cloud system. Accordingto the existing implementation of the cloud server's access control, thedoctor's action is permitted because the access control policies arestatic, meaning the devices used to gain access do not matter. Thiscould be a serious problem in some circumstances. For example, if thedoctor left his tablet in a public area unattended, the sensitiveprescription information of the patient could be available to those whofound the tablet. It is therefore necessary to tighten the accesscontrol policies so that mobile devices can only be used at times andfrom places where the system can be sure that the security of thesensitive information will be maintained.

In above scenario, ideally the doctor should not be able to access allthe files using any device in any circumstance. The access controlshould be context-aware, that is, according to certain embodiments, theaccess control should be adaptive to the context of use. When someoneattempts to access the prescription file using the doctor's tablet,access may be denied when the tablet is not within the doctor's workenvironment.

According to certain embodiments, there may be several preconditionsrelating to the context before access is permitted. These preconditionsmay include, but not limited to, for example: the tablet needs to beregistered in the hospital network which is currently using theencrypted hospital WiFi SSID; access happens within the office workinghours; and the location of access is within the hospital boundaries.Additionally, in other embodiments, files containing less sensitiveinformation may not have such restrictions.

According to certain embodiments, context-aware policy decisionrequirements may be formalized as in the following manner. For example,for access control policy decision requirements, a policy decision maybe required for a set of resources R to give a set of users U a set ofaccess permissions P, denoted by the predicate access:

access(R,U,P)  (R1)

For example, the doctor may always have read or write permissions on thepatient's record, but is not allowed to share it with anyone else, here:

access(PatientRecord,Doctor,{Read,Write})  (1)

Using role-based access control policies, the above rule may begeneralized to a group of users and a group of resources, for example,as follows:

access(PatientRecord,Doctor,{Read,Write})  (2)

In a context-aware access control policy decision requirement, acontext-aware policy decision may be required to give a set of user(s)U, a set of permissions P to access a set of resource(s)R, when the setof contextual attributes A satisfy a Boolean condition C(A), denoted byC(A)→access(R, U, P), or the following:

access(R,U,P)|C(A)  (R2)

With the above example, the doctor may get both Read and Write access tothe records only when he or she is in the hospital, within working hoursbetween 9 AM and 5 PM, denoted by the following:

$\begin{matrix}{{{{access}\left( {{PatientRecord},{Doctor},\left\{ {{Read},{Write}} \right\}} \right)}{GPSLocation}} = {{Hospital}{9 \leq {WorkingHour} \leq 17}}} & (3)\end{matrix}$

Here, GPS location and working hour are two variables introduced todifferentiate the varying contextual situations. To fully cover allpossible situations, a single context-aware policy decision requirementmay not be sufficient. In particular, it may be necessary to specify thepermissions for a collection of situation other than this one, and alsoindicate the default (otherwise) permissions. For example, when thedoctor is not within the remit of the above contextual situation, thepermissions will not be allowed. Such a situation may be represented asfollows:

access(PatientRecord,Doctor,{})GPSLocation≠Hospital∨(9≤WorkingHour≤17)  (4)

The greatest common denominators of all the permissions assigned todifferent contexts may be the intersection of all the context-awarepolicy decisions that are applicable to given users and resources. Beingable to specify the access control decision policies using contextualconditions may provide the additional accuracy and granularity inmanaging the access control properties.

Context-Aware Policy Administration Point (PAP) Requirements

In continuing with the above example with the doctor and patient,according to certain embodiments, the doctor may be at home and it isalready after the working hours. Suddenly, the doctor may receive a callfrom the hospital ambulance and emergency unit that the patient hasdeveloped a serious symptom and been transferred to the emergency room.Receiving the call and knowing the situation, the doctor needs toimmediately access the patient's medical records stored on the cloudserver and perform necessary changes which may include, for example,updating the recent diagnosis and lab test results. Even with the cloudsystem satisfying the additional context-aware policy decisionrequirements as previously stated, he may not be able to access thefiles because he is outside the hospital WLAN area at any time of theday for this type of access. In other words, the context-aware policyrules as defined are now too strict for such exceptional uses.

In order to specify a change to the existing context-aware accesscontrol policy rules, additional contextual information such aslocation, WiFi SSID, time of the day and the device ID may have alreadybeen collected by the context sensors on the mobile device, and thesecan then be taken into account to define a new set of context-awareaccess control policy rules for the emergent or exceptional scenario.Although the doctor is not able to access the patient's medical recordsinitially while at home, after getting the emergency call, the doctorcould, according to certain embodiments, be exempted from therestriction by the system administrator because of the evidence that hisdevice ID was already registered with the hospital system, and he couldprovide the authentication to prove himself as the identity he claims tobe on his laptop.

In this case, the restriction of using the SSID condition is no longerneeded, instead the doctor may use the current mobile 3G Internet toaccess those cloud files about the patient, but only through the laptopthat has been registered with the hospital. With the understanding ofthe possible risk associated with this relaxed condition, the permissionhe received for modifying the patient's records is restricted to addingassociation between the files already in the system, rather thancreating new files. Now that the doctor knows why he has been denied toaccess the patient's Medical Records and in what ways (e.g., switchingto the registered laptop), he could be given the limited but sufficientaccess to get his work done. Because of the emergency, a flag may beraised so that the system administrator also finds a way to provideexemptions with additional recorded evidence. To do so, it may involvethe system administrator changing the root policy according to theadditional contextual parameters of the emergency situation and givingtemporary access to the files, but in a more secured way.

According to certain embodiments, the requirements may be stated in thefollowing manner. For instance, in context-aware access control policyadministration requirements, given a context-aware access control policydecision requirement access(R, U, P)|C(A) as defined above, underexceptional conditions of contexts attributes C′(A′)→C(A), where C′≠Cand A′≠A, a super-set of permissions P′⊃P may be temporarily granted,denoted as:

access(R,U,P′)|C′(A′)

C′(A′)⇒=C(A)

P′⊃P∧C′⇒C∧A′⇒A  (R3)

In other words, the context-aware access control policy decision rulemay be refined by conditions on new contextual variables. For example,while the context-aware access control decision rule

access(PatientRecords,Doctor,GPSLocationHospital∨¬(9≤WorkingHour≤17)  (5)

denies the doctor from accessing the records, upon receipt of suchcomplaint, a new situation may be discovered that the above rule may berelaxed to include Read permission as long as the contextual attributeDeviceID has already been registered with the hospital. Such a scenariomay be shown as follows:

$\begin{matrix}{{{access}\left( {{PatientRecord},{Doctor},\left\{ {Read} \right\}} \right)}\left( {{{{GPSLocation} \neq {Hospital}}{\left( {9 \leq {WorkingHour} \leq 17} \right)}}{{{IsRegistered}({DeviceID})}}} \right)} & (6)\end{matrix}$

It may be assumed that the exceptional attributes have already beencollected in the system so that the system administrator could make aninformed decision and the information leading to such decisions can beaudited for future investigations. Since these exceptions are oftentemporary in nature, it is expected that it is not necessary to refinethe default policies every time. If such exceptions happen frequently,the system administrator may be entitled to refine the root policy rulesto make the exceptional policy permanent.

Comparison of Policy-Based Access Control with Respect to Context-AwarePAP Requirements

According to certain embodiments, a key to implement of thecontext-aware policy administration point requirement may be to havepolicies that are declarative and extensible. Such policies may take theform of rules. In terms of expressiveness, some policy-based accesscontrol frameworks such as KAoS and Rei may use an ontology to representthe semantically rich contextual information, while others such asPonder and XACML may use simple constraints on attribute values, asshown in the comparison Table 1.

TABLE 1 Comparison of policy-based access control solutions FeaturesKAoS Rei Ponder XACML Knowledge Yes Yes No No Spec. language DAML/OWLRDF-S Ponder XML Reasoning Theorem Prolog Event Automated formalismProver Engine Calculus Enforcement of PAP No No Yes Yes

Knowledge representations used by KAoS and Rei may be based on ontology,while Ponder and XACML may be based on first-order logic forexpressiveness. Ontology-based knowledge representation has theadvantages of being able to import and compose large number of existingknowledge representations through linked data. However, security ofinformation systems often encounters emergent properties from thecontextual knowledge domains. Therefore, it may not be possible tochoose knowledge representations encoded in ontology a priori to expressemergent contextual situations.

The ontology-based specification languages used by KAoS and Rei arerespectively DAML/OWL and RDF-S, which, in certain embodiments, may notbe mandatory. Ponder and XACML are both declarative, respectively in aproprietary and an open XML standard-based specification languages. Forthis reason, XACML-based policies may be more amenable to extension andcomposition with other systems.

In terms of tool support, KAoS may have a graphical editor, KPAT, forontology and policy management, while Rei may not yet have a GUIinterface. In contrast, Ponder may have a front-end graphical editor anda back-end compiler to manipulate the policy rules. The XACMLLight toolmay provide a basic text-based root policy document which can be editedby any XML-enabled tools. In addition, since the policies are stored onthe server, a service-oriented query and administration of the rootpolicy may be necessary, which makes it easier to compose with other Webservices.

Underlying the tool support at the back-end, policy-based reasoning mayneed to be carried out using some formalism. In KAoS, a Java-basedimplementation of a theorem prover may be provided to facilitate thereasoning tasks. In Rei, a Prolog-based reasoning engine may be providedto perform the reasoning. Both reasoning languages are a variant ofprogramming languages. In contrast, Ponder uses the Event Calculus andinvokes SAT solvers behind the scenes, while XACML reasoning is based onrule-based engine provided by the XACMLLight implementations. Given thatall of them have appropriate reasoning mechanisms, the main selectioncriterion is whether the formalism is easy to use and understand.Therefore, in certain embodiments, XACML is selected because it uses afamily notation (XML).

Additionally, whether or not the enforcement mechanism can be composedwith other software components at the server side may also be animportant selection criterion. KAoS does not provide such flexibilitybecause developers need to write the code of appropriate enforcers andinsert them as entities to access control. Rei does not provideenforcement beyond what's already specified in Rei reasoning engine.Ponder provides a Java interface to the enforcement agents, whilstXACMLLight supports PDP through a policy combination algorithm in theexposed Web service operations.

The knowledge representations of KAoS and Rei may be flexibly combinedwith other tools because ontology may be extended with domain dependentdescriptions of local entities. However, such domain dependentdescriptions may not always be available a priori for the run-timecontexts in which the cloud system being used. Ponder provides amanagement domain as a structuring technique for partitioning complexobject systems, while XACML may be extended with additional knowledgestructures given its extensible nature inherited from the XML standard.

Comparison of Access Control Frameworks with Respect toContext-Awareness PDP Requirements

When it comes to practical access control frameworks which supportparsing, interpretation, and strong typing, Ponder, X-FEDERATE, andXACML may be good candidates. Each has advantages and disadvantages, assummarized in Table 2.

TABLE 2 Comparison of practical policy-based access control solutionsFeature Ponder X-FEDERATE XACML Policy meta- IDL UML XML Schema modelingModality Precedence Rule Combination Rule Combination Static SoDMeta-policies SoD sets No Dynamic SoD No SoD sets No RBAC level 1 3 1Temporal No periodic time No contexts Non-temporal parameterized logicexpressions rule conditions contexts constraints

Although no of existing work directly supports context-awareness forintegrating mobile clients and cloud servers, some of them do providethe facility to support context-awareness. Both temporal andnon-temporal contexts may be supported, for example, by the periodictime expressions for temporal contexts using X-FEDERATE. Whilenon-temporal contexts may also be supported by all these threeframeworks, XACML is relatively more flexible to integrate differentschema through the name space extension of XML. Both X-FEDERATE andXACML are highly extensible, and the main difference between the two isthat X-FEDERATE assumes a federated/distributed access controlmechanism, while XACML does not impose any such assumptions. Accordingto certain embodiments, the access control policy engine may be hostedon the server side, which does not necessarily need federation.

In terms of the meta-models of policies, Ponder uses an interfacedefinition language (IDL), X-FEDERATE uses UML, and XACML does not limitthe XML Schema.

According to certain embodiments, precedence relationships may be usedin Ponder to resolve conflicts among the policies, while X-FEDERATE andXACML may use the rule combining models to deal with the conflicts. Thestatic separation of duty (SoD) conflicts may be checked usingmeta-policies in Ponder and Separation of Duty sets in X-FEDERATE, whilethe dynamic SoD conflicts may be checked as well in X-FEDERATE tosupport the Level 3 RBAC. XACML may not check the separation of dutyconstraints, and it may not need to do so because they are not requiredby Level 1 RBAC. In contrast, XACML may not require the admin overheadof policy management, the rule conditions are sufficient to specifynon-temporal contexts. The temporal contexts, however, may only besupported by the X-FEDERATE framework. In addition, given that certainembodiments propose context-aware access control solution concerns thepractical approach with centralized access control decisions, XACML isfound to be the suitable choice.

Design and Architecture

In order to satisfy the two key context-aware access control policyrequirements, certain embodiments have extended the architecture of thecloud system to integrate an XACML policy engine and a contextmonitoring framework. Referring to FIG. 4, there is shown an overview ofthe architectural design 400 for this framework according to certainembodiments.

At the mobile device 405 on the client side, a context sensor AWAREClient is installed as a mobile library service using the client-side ofthe AWARE framework. Information about end-users' devices, such astime-of-uses, GPS locations, WiFi SSID's, readings of accelerometers,etc. may be collected from the contextual sensors and sent periodicallyto the AWARE Web server 415 of the AIS server in the cloud 410 andrecorded into a relational database, AWARE DB 430. Although for a givenset of context-aware policy rules only a subset of context attributesmay be needed, the AWARE framework can collect as much contextualattributes as possible with the consent of users so that some of thesecould be used later on by the context-aware PAP.

With respect to the PDP requirements, when users browse on their mobiledevices for the files listed in the cloud server, access requests tothese files may be formulated and transmitted to the Cloud Web Server455, which decides on assigning the right permissions to the users bylooking up the database Cloud DB 465. The existing cloud server 455 mayimplement its own access control subsystem by only querying a‘PERMISSIONS’ table associated with the files, which was notcontext-aware.

Using the AWARE framework and XACML policy engine, the context-awareaccess control policy decisions (PDP) may be made on relevant contextualfactors together with a set of context-aware XACML root policies 435 asfollows.

First, the rule conditions of the access control policies may be anabstraction of the context variables collected from the end-users intothe AWARE DB 430. Second, the subjects and policy actions may bespecified using the XACML syntax and updated by the system administratorthrough the Context-Aware PAP 425 operations of XACMLLight Web Service440. The files 460 of similar access control properties may beaggregated using the existing cloud PERMISSIONS table and the newcontext-aware framework may generate additional contextual parameters,via the NuSOAP bindings to the PHP programs 445 in the cloud server 455,as part of the requests to Context-Aware PDP 420 operations of theXACMLLight Web Service 440. Such policy decisions may mix thecontext-aware access control policies with the context-of-uses of thefiles 460 upon request, which facilitate both flexible and efficientcomputation of access control decisions.

If users are not satisfied with the access control decisions, theirfeedback on context-aware access control policies 470, together with therelated contextual information from the AWARE DB 430, may be sent to thesystem administrator 475 in order to consider updating the XACML rootpolicy rules that implement the context-aware PAP requirements. Both thecloud server 455 and AWARE Web servers 415 may be implemented on top ofApache Web servers, and the XACMLLight Web service 440 is implemented ontop of Apache Axis2 framework.

Implementation and Evaluation

Interfacing Cloud Server with PAP and PDP in XACML-Light Web Services

According to certain embodiments, a cloud-based server has beenimplemented in PHP, a popular programming language for designing Webapplications, while XACML is a Web-service based standard which has areference implementation called XACMLLight. Even though the underlyingprogramming language for XACMLLight is Java, it was thought to bestraightforward to integrate them because Web services provideprogramming language agnostic interoperability between heterogeneousfunctions as long as they are compliant to the standard interfaces suchas WSDL and messaging formats such as SOAP.

Referring to FIG. 5, there is shown an example policy in XML, whichexpresses a doctor requesting read access to the patient's recordaccording to certain embodiments. As shown in FIG. 5, the doctor isrepresented as “Doctor Bob” and the patient is referenced as “Alice”.Here, the access control policy variables for subject and resources(e.g., “Doctor=Bob′ and “PatientRecord=Alice”) are obtained from thecloud-based systems directly.

Referring to FIG. 6, there is shown an example policy of the root policyrule in XACML according to certain embodiments, which defines thepermissions for Bob the Doctor to have the READ access Patient's Recordof Alice only when both of the two Boolean conditions“isGPSWithinHospital” and “isWorkingHour” are true.

The policy of FIG. 6 instantiates the context-aware PDP requirement in(5) by evaluating the condition as two sub-conditions:“isGPSWithinHospital” as Latitude∈(25.287¬0.005, 25.2867+0.005),Longitude∈(51.53−0.005, 51.53+0.005) (according to Doha Hospital's GPSlocation) and “isWorkingHour” as “WorkingHour∈[9, 17]”. Bothsub-conditions evaluated to false for the example request, therefore,the decision response is “Deny” in this example. Referring to FIG. 7,there is shown an example policy of the denial of the decision responsein view of the policy of FIG. 6.

However, a question may arise of how it may be possible to know from thecloud-based server's XACMLLight request, the concrete GPS locations andworking hours if they were not collected by the original cloud-basedsystem. The contextual variables “Latitude=52.04”, “Longitude=0.76′”,“WorkingHour=20” may only be obtained from the AWARE DB 430, not fromthe cloud server 455, and their implementation are integrated withXACMLLight by modifying the implementation of the class PDPImpl java toread the specification of context-aware conditions denoted by theadditional attribute origin=“Aware” we introduced to the“EnvironmentAttributeDesig-nator” elements.

In addition to this extension to the XACML schema, according to certainembodiments, also introduced was a separate declaration for thecontext-aware conditions, by reusing the XACML schema for “Condition”.With reference to FIG. 8, there is shown an example policy forspecifying conditions of the “isGPSWithinHospital” and “isWork-ingHour”.

As can be seen, the XML-based request-response pair shown in FIG. 8requires the SOAP XML messages to be generated or parsed automatically.However, such integration can be more complex. First of all, the PHP webservices may require an additional layer to arbitrate how the datastructures in PHP are mapped to the SOAP messages. For this purpose,according to certain embodiments, NuSOAP may be selected, which offersthe basic means to package PHP parameters into SOAP arguments for Webservices. To integrate request/response SOAP messages to and from theXACMLLight web services, the NuSOAP PHP bindings may be used. Thedefault implementation of NuSOAP may produce a SOAP envelope wrapper inXML format of a simple PHP data structure. However, XACML Web servicesrequests may include complicated data structures, which involve nestedmaps with predefined key names. According to certain embodiments, inorder to build such complicated SOAP messages automatically withoutchanging the WSDL interface, changes in nusoap.php binding file weremade to produce the required SOAP messages from any native PHP datastructures.

Secondly, according to certain embodiments, XACMLLight may bereconfigured for the underlying Axis2 server to provide it as a Webservice. The default configurations in the documentation of XACMLLighton Axis server may not be sufficient for this purpose. In certainembodiments, changes may be made to the useOriginalWSDL variable fromtrue to false in the META INF/services.xml file inside the authz.aararchive located at the axis2-1.6.2/repository/services folder. Incertain embodiments, to change this parameter value, one needs to firstextract the authz.aar and change the value in both places (i.e.,respectively for both PDPService and PAPService) where the variable isused, then repackage it to replace the original authz.aar in place.

To implement PDP, the other side of the binding between the cloud-basedserver and XACMLLight is to insert additional instructions to invokecloud/apps/files/index.php when a file is accessed, which generate theSOAP message required by the WSDL operations of the XACMLLight Webservice. In this way, the parameters may be created directly from thecontrol variables such as the subject user, in order to form the requestSOAP message. The message may then be evaluated by the PDP operations ofXACMLLight policy engine, and the response from the PDP operations ofpolicy engine may also be fetched from the message, returned to thecontrol of the modified cloud program as native PHP variables via NuSOAPbindings.

In certain embodiments, after the above changes, the PDP parameters maystill be static, which need to be connected to the context monitor inorder to satisfy the context-aware PDP requirements. For example, theAWARE DB 430 contextual data may be fetched from the database as queriesimplemented by the modified XACMLLight so that the context variablesreferenced by the rule conditions in XACML policies can be evaluated atrun-time. Due to the separation of concerns of Web services, suchimplementation may be isolated from the service interfaces. Therefore,the modified cloud system may not need to know exactly how thecomputation was done. It would allow future integration of thecontext-aware self-adaptive access control with other legacy softwaresystems.

Similar to the above changes to the PDP operations, in otherembodiments, PAP operations of XACMLLight were wrapped so that they canbe used to reconfigure the root policy of XACMLLight by the systemadministrators. When a user sees the denial of a certain access requestto a file, on the cloud-based server Web interface, “Info” button may beadded to explain the decisions made by the system. As a side effect ofsuch explanation, the contextual information of the AWARE DB 430 inrelation to the access decision may notify the system administrator atthe back-end. On reflection of the frequent complaints from users, thesystem administrator may specify the root access control policy rulesdifferently and create a PAP request to the XACMLLight Web service toupdate the XACML root policy rules. The administrators may be trusted tomake the right changes to the policies. At the same time, all thechanges made by the system administrator may be logged, along with thelogs of the contextual information in relation to users' requests forfuture auditing purposes.

Setting Up Context-Aware Server Through Web Services and AWARE MobileClients

Next, details of how to make the modified cloud Web server aware of themobile contexts of individual users through the AWARE framework isprovided, and how to further connect the data through the modifiedXACMLLight Web service.

Because the AWARE framework uses a relational database on the serverside, in certain embodiments, the RDB configurations may first be setup. The cloud-based server may use databases internally. Thus, accordingto certain embodiments, the same database management system may beshared to simplify the solution. In other embodiments, the businesslogic may be separated from access control data, therefore the twodatabases may be stored separately using different docker sub-containersto avoid tainting each other in a multi-tenant cloud environment.

Database Setup Using Docker Containers

According to certain embodiments, an empty database (e.g., MYDATABASE)may be created on a MySQL server, and assign it a user MYDATABASEUSERand password MYDATABASEPASS-WORD. The first time an AWARE Clientconnects to the server, the database may automatically be created. Thisis where the data collected on the mobile phone may be replicated.Because of the docker container, it is possible to make sure that thesame database management system (e.g., MySQL) is storing the data ondifferent volumes on the server.

Server Dashboard

According to certain embodiments, the AWARE Server Dashboard may allowone to remotely manage an experiment, or request the data to be sent toa cloud server. Using the MQTT protocol, it may be possible to extendthe supported commands to particular needs. Referring to FIG. 9, thereis shown a method of setting up an AWARE Server dashboard according tocertain embodiments. In the exemplary method of FIG. 9, suppose YOURHOSTis the server domain or IP address.

As shown in FIG. 9, at step 910, the contents of the .zip is copied, andthe instructions assume that AWARE is in the root of the HTTP folder ofthe cloud server. At step 920, the php database file is modified tomatch the server configuration. Further, at step 930, the config phpfile is modified to protect the web services dashboard with an encryptedsession. At step 940, the aware_ws php file is modified to match thecloud server configuration.

The status of the web-service may be checked athttp://OURHOST/AWARE/index.php, and the following URL displays the AWAREServer Dashboard: http://ais.qu.edu.qa/AWARE/index.php/awarews/dashboard.

According to certain embodiments, the dashboard may ask one toauthenticate, which can be provided as MYADMINISTRATIONUSER.

Setting Up AWARE Client to Use the AWARE Server According to CertainEmbodiments

Once the AWARE Server is setup (web service), one can add server detailsin the AWARE Client application by connecting the mobile device to theinternet (network data plan or WiFi).

Configuring the Web Server on the Client

Once connected, one can open the AWARE Client application on the mobiledevice, and activate the ‘AWARE Server Web-services’ by setting it tohttp://YOURHOST/AWARE/index.php/aware_ws/index.

Once activated, the client may start pushing data to the MySQL databaseon the server using the above service. With reference to FIG. 10, thereis shown a method according to certain embodiments, for connectingXACMLLight Web service with the AWARE Web server. In step 1010, a newJAVA Class with XACMLLight code in the PDP package namedContextAttributes is added to read the latest context value from theAWARE DB 430. At step 2, a JDBC driver is registered and a connection tothe AWARE DB 430 is opened. At step 1030, a SELECT query is executed tofetch the data needed using the extracted result sets. At step 1040, theexisting PDPIMpl class of XACMLLight implementation is modified byadding in the getMatchingPolicies( ) method the instructions to get thecontextual attributes from the matching policy. At step 1050,ContextAttributes class is invoked to fetch data from the AWARE DB 430corresponding to the context variables read from the triggered policy.At step 1060, the environmental attributes in the XACML request isreplaced with the updated values read from the AWARE DB 430 in theevaluate( ) method.

The Interaction of the “Info” Button on the Cloud-Based Server

In the implementation, the decision log may be stored in the modifiedcloud-based server database for each request made to the XACMLLightpolicy engine. On the Web interface of the original cloud-based server,files may be shown as a list to users with permission to access them.Along with each file is a hyperlink to open the content and a fewbuttons on the hover menu to perform additional actions such as Rename,Download, Share, etc. Therefore, these capabilities may form theoriginal cloud-based server must be kept if the decision from the XACMLPolicy engine is “Permit”. However, if the decision is “Deny”, the hyperlink and those hover buttons will not be shown. Instead, an “Info”button may be placed next to the file item for user to know anexplanation why the access was denied on this file. Furthermore, thepolicy administration may receive from the AWARE DB 430 rows of contextlogs within 5 minutes of the time when user received the “Deny”decision, only if the user has clicked the “Info” button. These roles,together with the rules that deny the access, will be presented to thesystem administrator as feedback to help change to the policyaccordingly.

According to certain embodiments, in the Permissions.php program of thecloud-based server, while the request is made to access the file, theXACMLLight policy engine may be invoked, which may read the context fromthe modified PDPImpl.java library program in XACMLLight to determinewhich policy rule needs to be applied for the request arrived. Accordingto the matching policy among the root policy rules, the modifiedXACMLLight may return the access control decision back to thepermission.php program in the cloud-based server. At this point, the loghas been stored with an auto assigned request number, the policy ruleapplied, the decision made, the contexts read, etc. Therefore, if thereis a deny decision made according to the policy rule, the partlist.phpprogram of the cloud-based server will generate a list of files that donot have the Permit decision, without showing any link to open and anybutton of permitted actions.

The “Info” button may also enable users to find out which policy rulewas used according to which context, when a deny decision was made. Ifthe user wants to have an emergent, temporary, but secure access of thefile, s/he could proceed from that point and raising the emergency flag,given that necessary authentications have been granted. After the systemadministrator reacted to complaint request by updating the policy ruleusing the PAP operations of XACMLLight Web service, the user may beprovided with temporary access permissions to requested file.

In certain embodiments, existing XACMLLight PDP may receive a requestfile that contains a subject, an object, an action and severalcontextual attributes. According to those values, PDP may choose theright rule to apply from the root policy. When the request was generatedautomatically as the user tries to access the files, not all values ofthese contextual attributes and their relevance may be fully known atthe decision time. Therefore, in certain embodiments, a decision has towait for collecting all these values, which might slow down the process.

To be more efficient, according to certain embodiments, the existing maybe modified to read the request subject, object and action values andmatch them with the root policy to determine which rule would be appliedto address this particular request. Then from that particular rule, onlythose relevant contextual attributes would need to be evaluated. Bindingthese values with the existing request file, the modified PDP may useall the root policy rules together to obtain the access controldecision, which could save resource, time and process by reading onlythose required and current values. The modified implementation added anew class ContextAttributes java into the PDP package of existingXACMLLight, which reads and returns required attribute values to theclass PDPImpl java to determine the access control decision.

Referring to FIG. 14, there is shown a system according to certainembodiments. It should be understood that each of FIGS. 1 through 13 maybe implemented by various means of their combinations, such as hardware,software, firmware, one or more processors and/or circuitry. In oneembodiment, a system may include several devices, such as, for example,user device 110, or server 120. The system may include more than onedevice 110, and server 120, although only one of each of these devicesis shown in FIG. 14 for the purposes of illustration.

Each of the devices shown in FIG. 14 may include at least one processoror control unit or module, respectively indicated as 111, and 121. Atleast one memory may be provided in each device, and indicated as 112,and 122, respectively. The memory may include computer programinstructions or computer code contained therein. One or more transceiver113 and 123 may be provided, and each device may also include anantenna, respectively illustrated as 114 and 124. Although only oneantenna each is shown, many antennas and multiple antenna elements maybe provided to each of the devices. Other configurations of thesedevices, for example, may be provided. Other configurations of thesedevices, for example, may be provided. In certain embodiments, the userdevice 110 may be a mobile phone or smart phone or multimedia device, acomputer, such as a tablet, provided with wireless communicationcapabilities, personal data or digital assistant (PDA) provided withwireless communication capabilities, portable media player, digitalcamera, pocket video camera, navigation unit provided with wirelesscommunication capabilities or any combinations thereof. In otherembodiments, the server 120 may be a cloud server, system server, or anyother similar type devices.

Transceivers 113 and 123 may each, independently, be a transmitter, areceiver, or both a transmitter and a receiver, or a unit or device thatmay be configured both for transmission and reception. In otherembodiments, the user device or server may have at least one separatereceiver or transmitter. The transmitter and/or receiver (as far asradio parts are concerned) may also be implemented as a remote radiohead which is not located in the device itself, but in a mast, forexample. The operations and functionalities may be performed indifferent entities, such as nodes, hosts or servers, in a flexiblemanner. In other words, division of labor may vary case by case. One ormore functionalities may also be implemented as virtual application(s)in software that can run on a server.

Processors 111, and 121 may be embodied by any computational or dataprocessing device, such as a central processing unit (CPU), digitalsignal processor (DSP), application specific integrated circuit (ASIC),programmable logic devices (PLDs), field programmable gate arrays(FPGAs), digitally enhanced circuits, or comparable device or acombination thereof. The processors may be implemented as a singlecontroller, or a plurality of controllers or processors.

For firmware or software, the implementation may include modules or unitof at least one chip set (for example, procedures, functions, and soon). Memories 112, and 122 may independently be any suitable storagedevice, such as a non-transitory computer-readable medium. A hard diskdrive (HDD), random access memory (RAM), flash memory, or other suitablememory may be used. The memories may be combined on a single integratedcircuit as the processor, or may be separate therefrom. Furthermore, thecomputer program instructions may be stored in the memory and which maybe processed by the processors can be any suitable form of computerprogram code, for example, a compiled or interpreted computer programwritten in any suitable programming language. The memory or data storageentity is typically internal but may also be external or a combinationthereof, such as in the case when additional memory capacity is obtainedfrom a service provider. The memory may be fixed or removable.

The memory and the computer program instructions may be configured, withthe processor for the particular device, to cause a hardware apparatussuch as user device 110, or server 120, to perform any of the processesdescribed above, including, for example, at least those shown in FIGS.1-13 and 15. Therefore, in certain embodiments, a non-transitorycomputer-readable medium may be encoded with computer instructions orone or more computer program (such as added or updated software routine,applet or macro) that, when executed in hardware, may perform a processsuch as any one of the processes described herein. Computer programs maybe coded by a programming language, which may be a high-levelprogramming language, such as objective-C, C, C++, C #, Java, etc., or alow-level programming language, such as a machine language, orassembler. Alternatively, certain embodiments may be performed entirelyin hardware.

FIG. 15 illustrates another method according to certain embodiments. Themethod illustrated in FIG. 15 includes, at 510, determining, at a cloudserver, the validity of user credentials received from a user device.The method can also include, at 520, receiving context data related tothe user device based on the validity of the user credentials. Inaddition, the method may include, at 530, synchronizing the context datawith the cloud server. Further, the method may include, at 540,enforcing context-sensitive security checks on requests made by the userfor resources based on the sensor data collected by the user device. Inaddition, at 550, the method may include determining if the requests forresources are compliant with access control policies of the cloud serverin addition to enforcing the context-sensitive security checks.

Certain embodiments may be directly applicable in cloud-based softwaresystems that adapt their security mechanisms in response to contextualchanges in the environment of the users. For instance, certainembodiments may be used in the development method of cloud-based filesharing applications. Other applications of certain embodiments mayinclude, for example, in existing cloud-based file storage applications,creating a plug-in in order to support security needs of individualusers or to support organizational security policies amongst a set ofusers. Such a plug-in may be offered by the owners of the cloud-basedfile storage application services themselves, or by a third-party vendoras an additional application, or by organizations that use thecloud-based file storage application to manage file-sharing tasks.

A further application of certain embodiments may include a newcloud-based file storage application that may offer adaptive security asa built-in feature, either when competing directly with existingservices, or when differentiating from the existing services. Further,other embodiments may be applicable to any cloud-based system wheresecurity mechanisms are implemented as a rule-based access controlsystem that needs to take into account the contextual factors.

Additionally, certain embodiments may provide distinct advantages. Forexample, according to certain embodiments, it is possible to provide anAIS architecture that provides security checks in addition to securitypolicies, and work with both existing as well as new cloud-based webapplications. According to other embodiments, neither the client-sidesoftware, nor the server-side software needs modification. The contextsensing by the In Monitor and Out Monitor may run in parallel to theclient-side software. Similarly the Adaptation Engine may run as awrapper to the access control engine on the server side. Such featuresmay make the method and system of certain embodiments generic andapplicable to a range of software systems.

According to other embodiments, it may be possible for the AdaptationEngine to be designed in a way that it performs additional checks forsecurity, rather than remove the checks by the policy engine. In otherwords, adaptation may ensure a higher degree of security. Additionally,in further embodiments, it may be possible for the In Monitor, OutMonitor, and Adaptation Engine to be generic and be implemented in anumber of ways. That is, it may be possible for the user to choose toimplement their own tools or use third-party tools for this.

According to certain embodiments, it is possible to define thecontext-aware access control policy decision and administrationrequirements that were not supported by the vanilla cloud-based serversoftware solution. In certain embodiments, is possible to achieveenhanced availability for the cloud-based storage service by: (a)re-engineering the cloud-based server with the standard-compliantattribute-based access control XACMLLight library, and the mobile clientof the AWARE framework for collecting contextual attributes; and (b)extending XACML to declare context-aware conditions for interpretingcontextual variables for the XACML root policy rules. As part of thisprocess, the design rationale and implementation considerations in theentire solution were discussed. After evaluating the solution with acontrolled experiment, it is possible to demonstrate the advantage ofsatisfying the context-aware access control requirements.

Although the foregoing description is directed to the preferredembodiments of the invention, it is noted that other variation andmodifications will be apparent to those skilled in the art, and may bemade without departing from the spirit or scope of the invention.Moreover, features described in connection with one embodiment of theinvention may be used in conjunction with other embodiments, even if notexplicitly stated above.

According to a first embodiment, a method of controlling access to dataheld in the cloud may include monitoring user context by collectingsensor data relating to a user device operated by a user. The method mayalso include synchronizing the collected sensor data to a cloud server.The method may further include enforcing context-sensitive securitychecks on requests made by the user for resources based on the collectedsensor data.

We claim:
 1. A method for controlling access to data held in the cloud,comprising: determining, at a cloud server, the validity of usercredentials received from a user device; receiving context data relatedto the user device based on the validity of the user credentials;synchronizing the context data with the cloud server; and enforcingcontext-sensitive security checks on requests made by a user forresources based on sensor data collected by the user device, wherein thecontext data comprises data about an operational state of the userdevice itself.
 2. The method for controlling access to data held in thecloud according to claim 1, wherein the context data comprises dataabout a state of a physical world outside of the user device.
 3. Themethod for controlling access to data held in the cloud according toclaim 2, wherein the context data about the state of the physical worldoutside of the user device comprises a user identity, a globalpositioning system location of the user device, and an accelerometerreading.
 4. The method for controlling access to data held in the cloudaccording to claim 1, wherein the context data about the state of theuser device itself comprises applications running on the user device ata given time, a battery level of the user device, and screen brightnessof the user device.
 5. The method for controlling access to data held inthe cloud according to claim 1, wherein access to the resources issubject to one or more preconditions related to the context data.
 6. Themethod for controlling access to data held in the cloud according toclaim 1, further comprising determining if the requests for resourcesare compliant with access control policies of the cloud server inaddition to enforcing the context-sensitive security checks.
 7. Themethod for controlling access to data held in the cloud according toclaim 1, wherein the context-sensitive security checks varies based on asensitivity level of the resources.
 8. A cloud server that forcontrolling access to data held in the cloud, comprising: at least oneprocessor; and at least one memory including computer program code,wherein the at least one memory and the computer program code areconfigured to, with the at least one processor, cause the apparatus atleast to determine, at a cloud server, the validity of user credentialsreceived from a user device; receive context data related to the userdevice based on the validity of the user credentials; synchronize thecontext data with the cloud server; and enforce context-sensitivesecurity checks on requests made by a user for resources based on sensordata collected by the user device, wherein the context data comprisesdata about an operational state of the user device itself.
 9. The cloudserver according to claim 8, wherein the context data comprises dataabout a state of a physical world outside of the user device.
 10. Thecloud server according to claim 9, wherein the context data about thestate of the physical world outside of the user device comprises a useridentity, a global positioning system location of the user device, andan accelerometer reading.
 11. The cloud server according to claim 8,wherein the context data about the state of the user device itselfcomprises applications running on the user device at a given time, abattery level of the user device, and screen brightness of the userdevice.
 12. The cloud server according to claim 8, wherein access to theresources is subject to one or more preconditions related to the contextdata.
 13. The cloud server according to claim 8, wherein the at leastone memory and the computer program code are further be configured to,with the at least one processor, cause the apparatus at least todetermine if the requests for resources are compliant with accesscontrol policies of the cloud server in addition to enforcing thecontext-sensitive security checks.
 14. The cloud server according toclaim 8, wherein the context-sensitive security checks varies based on asensitivity level of the resources.
 15. A computer program, embodied ona non-transitory computer readable medium, the computer program, whenexecuted by a processor, causes the processor to: determine, at a cloudserver, the validity of user credentials received from a user device;receive context data related to the user device based on the validity ofthe user credentials; synchronize the context data with the cloudserver; and enforce context-sensitive security checks on requests madeby a user for resources based on sensor data collected by the userdevice, wherein the context data comprises data about an operationalstate of the user device itself.
 16. The cloud server according to claim15, wherein the context data comprises data about a state of a physicalworld outside of the user device.
 17. The cloud server according toclaim 16, wherein the context data about the state of the physical worldoutside of the user device comprises a user identity, a globalpositioning system location of the user device, and an accelerometerreading.
 18. The cloud server according to claim 15, wherein the contextdata about the state of the user device itself comprises applicationsrunning on the user device at a given time, a battery level of the userdevice, and screen brightness of the user device.
 19. The cloud serveraccording to claim 15, wherein access to the resources is subject to oneor more preconditions related to the context data.
 20. The cloud serveraccording to claim 15, wherein the computer program, when executed bythe processor, further causes the processor to determine if the requestsfor resources are compliant with access control policies of the cloudserver in addition to enforcing the context-sensitive security checks.21. The cloud server according to claim 15, wherein thecontext-sensitive security checks varies based on a sensitivity level ofthe resources.